be: tell transfers from card payments and filter by it, recorded live pending and booked - #43

A card payment was read live, pending on 2026-11-07 and booked on 2026-11-10, and the client now says how each movement was made and filters by it:

var me = moneta.with(token);   // the token bound once; cheap, holds nothing but the two
me.transactions().between(from, to).transfers().outgoing().list();
me.transactions().between(from, to).cards().booked().list();
me.transactions(accountId).between(from, to).incoming().list(); // a token with several accounts

Transaction.method() is TRANSFER, CARD or OTHER, read from clearingSystemReference with the BLOCKED_ prefix a pending movement carries dropped. OTHER covers fees, interest, ATM withdrawals and whatever else has not been seen live yet: #66. The query is immutable and reads nothing until list(); only between is required, the rest is optional, and since MONETA filters by date only, it reads the whole range and drops the rest in the client.

Both card payments are recorded: live/pending-card.json (account, reference and merchant replaced) and live/booked-card.json (account and symbols replaced; the card number, already masked by MONETA, and the merchant kept). .docs/moneta-api.md sets them side by side.

What booking changed:

• the merchant moves from creditor.name (40 characters at fixed widths) to transactionDescription (30 characters, a different text), so counterpartyName() falls back to the description for a card payment;
• the booked amount matched the hold, and the booked movement replaced the pending one;
• the bank transaction code's sixth digit went from 3 to 2, which may mean pending; one payment, said as an inference;
• a booked card payment adds the masked card number (chequeNumber), PLATBA KARTOU ONLINE and a purpose; not mapped.

method is a new Transaction component before raw, which the docs allow before 1.0; the café's tests construct it and got the extra argument. The README's "Card transactions" row stays unticked: that is MONETA's own card endpoint, behind the portal.

Without an account id, the holder reads the only account the token opens, once, and remembers it, so a poller keeping the holder makes no extra request; a token with several accounts is refused. .docs/usage.md is cut to what a caller needs, with a collapsed Kotlin version under each Java example.

Checked: make build green; tests for the pending and the booked card payment, booked transfers, and the query (each step, a replaced step, a card payment, no dates refused before any request, the only account read once per holder, a token with two refused). The Java and Kotlin doc examples compile against the built jar.

Still open, for later:

• a hold that lapses without a booked payment, not seen yet
• once the portal documentation opens (docs: read the portal documentation once the registration is approved #11): the "pending card transactions" endpoint and what the transaction code's digits mean